This would be a welcome change, as I'm also blocked by the current behavior.

Since I use yarn for all my (mono)repos, I created semantic-release-yarn which supports monorepos natively

@travi @gr2m this seems like a good idea, is there anything I could do to help get this over the line?

we are pretty strongly against adding code to core or official plugins that is specifically for projects that are monorepos. if someone would like to send us PRs, we are happy to better document workarounds like using npmrc, publishConfig in the package.json, or npm environment variables that can enable these sorts of things without changes to semantic-release. if someone knows a solution to this issue without adding a flag, please let us know.

adding things like this add extra complexity to the project that we have to maintain and not break over time that are only there for unsupported use cases. we have a hard enough time keeping up with the use cases we do officially support. we do try to avoid doing things specifically to prevent use in monorepos, but we do not support them officially so priority is very low if changes are needed to the official projects to enable that to work beyond what the community provides to extend the official projects.

@travi I see. As far as this issue goes, it seems like npm behavior is still wrong...waiting to hear confirmation from them that whoami shouldn't be able to work in workspaces.

FWIW, I've been using semantic-release for pnpm monorepos in my work for awhile now, without any special plugins. The only fix I needed to get it working was #531, and I think that fix is justified even for single package repo use cases. (I didn't run into this issue because the workspaces npm config option isn't a requirement for working with monorepos.) The only thing that was really difficult was configuring the conventional-changelog tools to distinguish commits by subpackage scope. Their config format isn't as powerful as I'd like so it wasn't pretty, but I at least got it working.